home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / rfc / rfc1538 < prev    next >
Text File  |  1993-10-05  |  21KB  |  564 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                            W. Behl
  8. Request for Comments: 1538                            McDATA Corporation
  9. Category: Informational                                      B. Sterling
  10.                                                       McDATA Corporation
  11.                                                                W. Teskey
  12.                                                             I/O Concepts
  13.                                                             October 1993
  14.  
  15.  
  16.            Advanced SNA/IP : A Simple SNA Transport Protocol
  17.  
  18. Status of this Memo
  19.  
  20.    This memo provides information for the Internet community.  It does
  21.    not specify an Internet standard.  Distribution of this memo is
  22.    unlimited.
  23.  
  24. Abstract
  25.  
  26.    This RFC provides information for the Internet community about a
  27.    method for establishing and maintaining SNA sessions over an IP
  28.    internet.  While the issues discussed may not be directly relevant to
  29.    the research problems of the Internet, they may be interesting to a
  30.    number of researchers and implementors.  Any questions or comments
  31.    relative to the contents of this RFC may be sent to the following
  32.    Internet address: snaip@mcdata.com.
  33.  
  34. Table of Contents
  35.  
  36.    1. Introduction..................................................  2
  37.    2. Motivation and Rationale......................................  2
  38.    3. SNA/IP Protocol Specification.................................  3
  39.    3.1 Glossary.....................................................  3
  40.    3.2 Conventions and Assumptions..................................  3
  41.    3.3 The Protocol.................................................  3
  42.    3.3.1 Connection Establishment...................................  3
  43.    3.3.2 Data Transfer..............................................  5
  44.    3.3.3 Connection Termination and Loss............................  6
  45.    3.3.4 Session Data Flow..........................................  7
  46.    3.3.5 State Transition Table for the Initiating Node.............  8
  47.    4. LLC to SNA/IP Conversion......................................  8
  48.    5. Performance...................................................  8
  49.    6. VTAM Definition...............................................  9
  50.    7. Acknowledgments...............................................  9
  51.    8. References....................................................  9
  52.    9. Security Considerations....................................... 10
  53.    10. Authors' Addresses........................................... 10
  54.    11. Disclaimer................................................... 10
  55.  
  56.  
  57.  
  58. Behl, Sterling & Teskey                                         [Page 1]
  59.  
  60. RFC 1538                    Advanced SNA/IP                 October 1993
  61.  
  62.  
  63. 1.  Introduction
  64.  
  65.    Advanced SNA/IP suggests a method for the transmission of SNA session
  66.    data over an IP network.  This memo documents the SNA/IP protocol as
  67.    implemented in the McDATA LinkMaster(R) 6200 Network Gateway, McDATA
  68.    LinkMaster(R) 7100 Network Controller, and I/O Concepts X-Direct
  69.    TN3270 Server.
  70.  
  71.    Advanced SNA/IP differs from other protocols designed to enable
  72.    routing of SNA session traffic over an IP network.  SNA/IP was
  73.    originally designed for implementation in peripheral network nodes
  74.    like SNA gateways and downstream nodes (DSNs).  It is the authors'
  75.    view, however, that SNA/IP could also be implemented in intermediate
  76.    network nodes like routers as the base for an LLC to IP subnet
  77.    gateway or data link switch function.
  78.  
  79. 2.  Motivation and Rationale
  80.  
  81.    The token-ring media access control (MAC) protocol 802.5 and logical
  82.    link control (LLC) protocol 802.2 were the first set of LAN protocols
  83.    used to provide a reliable and connection-oriented data link service
  84.    for SNA sessions in a LAN environment.
  85.  
  86.    McDATA's experience with transporting SNA over 802.5 networks led to
  87.    an 802.3/802.2 (Ethernet) based variation.  As prospective customers
  88.    were introduced to these Ethernet products, the question of
  89.    routability arose.  Network administrators, accustomed to working
  90.    with Ethernet networks and the IP-based protocols, required an IP
  91.    routable solution.  McDATA's "SNA over Ethernet" products were
  92.    bridgeable, but were not routable.
  93.  
  94.    SNA sessions require a reliable and connection-oriented data link.
  95.    TCP running over IP provides a reliable and connection-oriented
  96.    transport service and has the added benefit of being routable.  It
  97.    seemed the UDP and TCP protocols could be used in place of 802.2 Type
  98.    I and Type II levels of service used in traditional SNA token-ring
  99.    implementations.  Advanced SNA/IP was created as a result of these
  100.    observations.
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Behl, Sterling & Teskey                                         [Page 2]
  115.  
  116. RFC 1538                    Advanced SNA/IP                 October 1993
  117.  
  118.  
  119. 3.  SNA/IP Protocol Specification
  120.  
  121. 3.1.  Glossary
  122.  
  123.    Data Link Switching (DLSw) - This is best described as a routing
  124.    protocol used for the conversion of LLC-based SNA sessions to an IP
  125.    form.  The initial version of the DLSw protocol is documented in the
  126.    informational RFC 1434 [1].
  127.  
  128.    Downstream Node (DSN) - An SNA Physical Unit (PU) type 2.0 or 2.1
  129.    device connected to the SNA network via a LAN (802.5, 802.3, etc.) as
  130.    opposed to an SDLC, X.25, or channel connection.
  131.  
  132.    SNA Gateway - A device that provides a data link control (DLC)
  133.    conversion function for SNA PU type 5 (host) devices and LAN-
  134.    attached DSNs.
  135.  
  136.    Subnet SNA Gateway - A device connected to both a traditional SNA
  137.    token-ring segment and an IP network that performs local termination
  138.    of the LLC connections, a mapping function of source address to
  139.    destination IP address, and a conversion (switching) function of LLC
  140.    to IP.
  141.  
  142. 3.2.  Conventions and Assumptions
  143.  
  144.    Frame formats are shown starting with the IP header.  Other headers
  145.    will, of course, appear in the actual frames sent, but these headers,
  146.    and the numbers of them, will vary across MAC types.
  147.  
  148.    It is assumed the reader is familiar with both the standard SNA
  149.    protocol (to the extent it applies to SNA Gateway and DSN functions)
  150.    and the base set of TCP/IP protocols.  Where practical, the reader is
  151.    asked to refer to appropriate SNA and TCP/IP documentation.
  152.  
  153. 3.3.  The Protocol
  154.  
  155.    Conceptually, there are three phases to the Advanced SNA/IP protocol:
  156.    the Connection Establishment phase, the Data Transfer phase, and the
  157.    Connection Termination phase.
  158.  
  159. 3.3.1.  Connection Establishment
  160.  
  161.    Connection Establishment involves the exchange of logical XID packets
  162.    between the connecting end nodes and culminates in the establishment
  163.    of a TCP connection.  This process is similar to the IBM-specified
  164.    Test, XID, SABME and UA exchange used to establish a Type II 802.2
  165.    connection for SNA traffic [2].  In place of the 802.2 Type I
  166.    messages, SNA/IP defines the following set of UDP datagrams:
  167.  
  168.  
  169.  
  170. Behl, Sterling & Teskey                                         [Page 3]
  171.  
  172. RFC 1538                    Advanced SNA/IP                 October 1993
  173.  
  174.  
  175.   Logical Null XID
  176.  
  177.      Use: Sent by an initiating node (such as a DSN) when the
  178.           connection to another SNA node is desired.
  179.  
  180.           The Logical Null XID communicates the sending node's
  181.           desire to negotiate connection parameters.  Once those
  182.           parameters are established, the Logical Null XID
  183.           communicates the sender's TCP port to which a connection
  184.           is to be made.
  185.  
  186.      Format:
  187.  
  188.         ------------------------------------
  189.         | IP Header  |  UDP Header  | 0xBF |
  190.         ------------------------------------
  191.  
  192.         Source IP address:       The IP address of the initiating
  193.                                  node.
  194.         Destination IP address:  The IP address of the partner SNA
  195.                                  node.
  196.         Source UDP Port:         Must match the TCP port number to be
  197.                                  used in the eventual TCP connection.
  198.         Destination UDP Port:    A known port on the partner node
  199.                                  that expects SNA/IP datagrams.
  200.  
  201.  
  202.      XID Request
  203.  
  204.      Use: Sent in response to a Logical Null XID and requests the
  205.           receiving node to send a Logical SNA XID datagram.
  206.  
  207.      Format:
  208.  
  209.         ------------------------------------
  210.         | IP Header  |  UDP Header  | 0xBF |
  211.         ------------------------------------
  212.  
  213.         The source and destination IP and UDP port numbers follow,
  214.         logically, from those provided in the Logical Null XID
  215.         datagram.
  216.  
  217.         The format of the XID Request and Logical Null XID are the
  218.         same.  The two types are distinguished by the roles assumed by
  219.         the two nodes.  In current implementations, the DSN initiates
  220.         the XID exchange by sending the Logical Null XID.  The SNA
  221.         Gateway responds with the XID request.
  222.  
  223.  
  224.  
  225.  
  226. Behl, Sterling & Teskey                                         [Page 4]
  227.  
  228. RFC 1538                    Advanced SNA/IP                 October 1993
  229.  
  230.  
  231.  
  232.   Logical SNA XID
  233.  
  234.      Use: Sent in response to an XID Request and in the context of
  235.           SNA XID negotiation.
  236.  
  237.      Format:
  238.  
  239.         ----------------------------------------------------
  240.         | IP Header  |  UDP Header  | 0xBF | SNA XID data  |
  241.         ----------------------------------------------------
  242.  
  243.         For PU 2.0 nodes, the SNA XID data consists of a Format 0 XID
  244.         [3].
  245.         For PU 2.1 nodes, the SNA XID data consists of a Format 3 XID
  246.         [3].
  247.  
  248.  
  249.    A typical Connection Establishment data flow appears below.
  250.  
  251.  
  252.      Node 1                                    Node 2
  253.  
  254.      Logical Null XID ------------------------->
  255.                        <------------------------ XID Request
  256.      Logical SNA XID -------------------------->
  257.                        <------------------------ TCP SYN
  258.      TCP SYN ACK ----------------------------->
  259.                        <------------------------ TCP ACK
  260.  
  261.    Note:  The source UDP port of the Logical Null XID equals the
  262.    destination TCP port of the TCP SYN segment.
  263.  
  264.    Retries of the Logical Null XID by the initiating node should occur
  265.    periodically until an XID Request is received in reply. The frequency
  266.    of the retries is left up to the implementor.  The lower bound on the
  267.    retry timer should be more than the expected round trip time for a
  268.    packet on the network.
  269.  
  270. 3.3.2.  Data Transfer
  271.  
  272.    There are no special packets defined for the Data Transfer phase.
  273.    Once the TCP connection is established, SNA Request Units (RUs) may
  274.    be exchanged between the two end nodes.  The SNA session data appears
  275.    as TCP segment data.  The only added SNA/IP requirement is that each
  276.    SNA message consisting of a Transmission Header (TH),
  277.    Request/Response Header (RH) and an optional Request/Response Request
  278.    Unit (RU) be preceded by a two octet length field.  Examples of Data
  279.  
  280.  
  281.  
  282. Behl, Sterling & Teskey                                         [Page 5]
  283.  
  284. RFC 1538                    Advanced SNA/IP                 October 1993
  285.  
  286.  
  287.    Transfer frames are shown below.
  288.  
  289.       -------------------------------------------------------
  290.       | IP Header | TCP Header | SNA Msg 1 len | SNA Msg 1  |
  291.       -------------------------------------------------------
  292.  
  293.       ----------------------------------------------
  294.       | IP Header | TCP Header | SNA Msg 1 cont'd  ->
  295.       ----------------------------------------------
  296.            --------------------------------
  297.               | SNA Msg 2 len | SNA Msg 2 |
  298.            --------------------------------
  299.  
  300.    The length field is passed in big endian format.  0 is a valid length
  301.    value.
  302.  
  303.    The format of the SNA Message pieces are as defined by SNA [3].
  304.  
  305.    Reliable and sequential delivery of data is provided by the TCP
  306.    protocol [5,6].
  307.  
  308. 3.3.3.  Connection Termination and Loss
  309.  
  310.    Either SNA node may, at any time, terminate the logical SNA
  311.    connection by issuing a TCP-level FIN segment.  Dictates of the TCP
  312.    protocol apply to this termination process [5,6].
  313.  
  314.    A connection is also terminated, though not as cleanly, if a TCP
  315.    Reset segment is sent by either SNA node.
  316.  
  317.    Once a connection is terminated, a new connection may be established
  318.    by the process outlined in the Connection Establishment section.  For
  319.    reconnections made to the LinkMaster 6200 gateway, the same UDP
  320.    source port must be used by the initiating node.  This implies that
  321.    the same TCP port is used. This requirement stems from the fact the
  322.    gateway may not always be aware that a TCP connection has been
  323.    terminated.  This would happen if the DSN became disabled prior to
  324.    sending a FIN or Reset segment.  Under these circumstances, SNA host
  325.    resources remain allocated and a reconnection from a DSN, which the
  326.    host believes to already be in session, is not allowed.  By requiring
  327.    the DSN to use the same port when reestablishing a connection, the
  328.    LinkMaster 6200 is able to recognize when a reset of the host
  329.    connection is required.
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Behl, Sterling & Teskey                                         [Page 6]
  339.  
  340. RFC 1538                    Advanced SNA/IP                 October 1993
  341.  
  342.  
  343. 3.3.4.  Complete Session Data Flow
  344.  
  345.       Node 1                                    Node 2
  346.  
  347.      Logical Null XID ------------------------->
  348.       (UDP Datagram)
  349.      Logical Null XID ------------------------->
  350.       (UDP Datagram)
  351.                        <------------------------ XID Request
  352.                                                   (UDP Datagram)
  353.      Logical SNA XID -------------------------->
  354.        (UDP Datagram)
  355.                        <------------------------ TCP SYN
  356.                                                   (TCP Message)
  357.      TCP SYN ACK ----------------------------->
  358.        (TCP Message)
  359.                        <------------------------ TCP SYN
  360.                                                   (TCP Message)
  361.  
  362.       ****************** Connection Established *******************
  363.  
  364.                        <------------------------ SNA ACTPU
  365.                                                   (TCP Message)
  366.        SNA ACTPU Response --------------------->
  367.         (TCP Message)
  368.                        <------------------------ SNA ACTLU
  369.                                                   (TCP Message)
  370.        SNA ACTLU Response --------------------->
  371.         (TCP Message)
  372.                                    .
  373.                                    .
  374.                                    .
  375.                        <------------------------ TCP FIN
  376.                                                   (TCP Message)
  377.        TCP FIN ACK     ------------------------>
  378.         (TCP Message)
  379.                        <------------------------ TCP ACK
  380.                                                   (TCP Message)
  381.  
  382.       ******************** Connection Closed *********************
  383.  
  384.        Logical Null XID ----------------------->
  385.         (UDP Datagram)
  386.              .
  387.              .
  388.              .
  389.              .
  390.  
  391.  
  392.  
  393.  
  394. Behl, Sterling & Teskey                                         [Page 7]
  395.  
  396. RFC 1538                    Advanced SNA/IP                 October 1993
  397.  
  398.  
  399. 3.3.5.  State Transition Table for the Initiating Node
  400.  
  401.                              Transition State
  402.    Given State | No Conn | Null XID Sent | SNA XID Sent | Conn Estb
  403.    ------------+---------+---------------+--------------+-----------
  404.    No          |         | Internal Act. |              |
  405.    Connection  |         | Stimulus      |              |
  406.                |         | ---> Sends    |              |
  407.                |         |  1st Null XID |              |
  408.    ------------+---------+---------------+--------------+-----------
  409.    Null XID    |         |  Internal     | XID Request  |
  410.    Sent        |         | Timer Event   | Received     |
  411.                |         | ----> Resend  | ----> Sends  |
  412.                |         | Null XID      | SNA XID      |
  413.    ------------+---------+---------------+--------------+-----------
  414.    SNA XID     |         | Internal      | SNA XID      | Indication
  415.    Sent        |         | Timer Event   | Received     | that TCP
  416.                |         | ----> Resend  | ----> Send   | connection
  417.                |         | Null XID      | SNA XID      | is estb.
  418.                |         |               |              |
  419.    ------------+---------+---------------+--------------+-----------
  420.    Connection  | Indica- |               |              | SNA
  421.    Established | tion    |               |              | Session
  422.                | that    |               |              | Data
  423.                | TCP conn|               |              |
  424.                | term.   |               |              |
  425.  
  426.  
  427.    A gateway state transition table is not provided here because the
  428.    state transitions are dependent on the nature of the SNA host
  429.    interface (3172 Channel Protocol, 3174 Channel Protocol, SDLC, etc.).
  430.  
  431. 4.  LLC to SNA/IP Conversion
  432.  
  433.    The use of Advanced SNA/IP to convert conventional token ring- based
  434.    SNA traffic to a routable form is both conceivable and practical.
  435.    While interesting, a discussion of this application falls outside the
  436.    context of this RFC.  Very briefly, it can be said that an SNA/IP-
  437.    based "subnet SNA gateway" application could do many of the things
  438.    being discussed in the context of the DLSw specification [1].
  439.  
  440. 5.  Performance
  441.  
  442.    The performance of SNA sessions running over an SNA/IP connection
  443.    will be affected by the bandwidth available on the network and by how
  444.    much traffic is on the network.  SNA/IP is poised to take full
  445.    advantage of the prioritization and class of service enhancements
  446.    promised in the next generation of IP.  Today, SNA/IP can take
  447.  
  448.  
  449.  
  450. Behl, Sterling & Teskey                                         [Page 8]
  451.  
  452. RFC 1538                    Advanced SNA/IP                 October 1993
  453.  
  454.  
  455.    advantage of router packet prioritization schemes based on port
  456.    number.  SNA/IP also leaves intact the standard SNA class of service
  457.    prioritization protocol.
  458.  
  459.    Performance measures taken at McDATA comparing the throughput of
  460.    SNA/IP and LLC across a single token-ring segment showed
  461.    approximately a 15 percent decrease in the maximum transactions per
  462.    hour (1500 bytes to the DSN, 50 bytes out to the host) for SNA/IP.
  463.    This decrease is well within the expected levels given the added
  464.    processing requirements of TCP/IP over LLC in the LinkMaster 6200 and
  465.    LinkMaster 7100 operating environments.
  466.  
  467. 6.  VTAM Definition
  468.  
  469.    The host VTAM definition of SNA/IP downstream nodes is dependent on
  470.    the gateway implementation.  Downstream nodes may appear as switched
  471.    major nodes connected to an XCA or as downstream nodes connected to a
  472.    PU 2.0 controller [4].
  473.  
  474. 7.  Acknowledgments
  475.  
  476.    The authors wish to acknowledge that the definition of SNA/IP was a
  477.    collaborative effort involving many individuals ranging from
  478.    customers to sales and marketing personnel to engineers. Particular
  479.    thanks go to David Beal, Steve Cartwright, Tracey Floming, Audrey
  480.    McEwen, Mark Platte, Paul Schroeder, Chuck Weil, and Marty Wright,
  481.    who all played key roles in the development and testing of this
  482.    protocol and also in the editing of this RFC.
  483.  
  484. 8.  References
  485.  
  486.    [1] Dixon, R., and D. Kushi, "Data Link Switching: Switch-to-Switch
  487.        Protocol", RFC 1434, IBM, March 1993.
  488.  
  489.    [2] "Token-Ring Network Architecture Reference", IBM document #SC30-
  490.        3374-02.
  491.  
  492.    [3] "Systems Network Architecture Formats", IBM document #GA27-3136-
  493.        12.
  494.  
  495.    [4] "VTAM Resource Definition Reference", IBM document #SC31-6438-1.
  496.  
  497.    [5] Comer, D., "Internetworking with TCP/IP Volume I", Prentice Hall
  498.        1991.
  499.  
  500.    [6] Postel, J., "Transmission Control Protocol - DARPA Internet
  501.        Program Protocol Specification", STD 7, RFC 793, USC/Information
  502.        Sciences Institute, September 1981.
  503.  
  504.  
  505.  
  506. Behl, Sterling & Teskey                                         [Page 9]
  507.  
  508. RFC 1538                    Advanced SNA/IP                 October 1993
  509.  
  510.  
  511. 9.  Security Considerations
  512.  
  513.    This RFC does not address issues of security.  SNA level security
  514.    procedures and protocols apply when SNA/IP is used as the transport.
  515.  
  516. 10.  Authors' Addresses
  517.  
  518.    Wilfred Behl
  519.    310 Interlocken Parkway
  520.    Broomfield, Colorado  80021
  521.  
  522.    Phone:  303-460-4142
  523.    Email:  wil@mcdata.com
  524.  
  525.  
  526.    Barbara Sterling
  527.    310 Interlocken Parkway
  528.    Broomfield, Colorado  80021
  529.  
  530.    Phone:  303-460-4211
  531.    Email:  bjs@mcdata.com
  532.  
  533.  
  534.    William Teskey
  535.    2125 112th Ave. North East
  536.    Suite 303
  537.    Bellevue, WA  98004
  538.  
  539.    Phone:  206-450-0650
  540.    Email:  wct@ioc-sea.com
  541.  
  542.    Note: Any questions or comments relative to the contents of this RFC
  543.    should be sent to snaip@mcdata.com.  This address will be used to
  544.    coordinate the handling of responses.
  545.  
  546. 11.  Disclaimer
  547.  
  548.    McDATA, the McDATA logo, and LinkMaster are registered trademarks of
  549.    McDATA Corporation. All other product names and identifications are
  550.    trademarks of their respective manufacturers, who are not affiliated
  551.    with McDATA Corporation.
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Behl, Sterling & Teskey                                        [Page 10]
  563.  
  564.